abicc.
Using abicc allows the specific compiler calling
conventions to be hidden. The specific invocation for three
different revisions of the Reference Platform are noted in the
rest of this section. Each is different, and there
is no guarantee that the methods will not continue to
change. Thus, the suggested compilation method is
simply to set an equate in the Makefile:
-abi flag to cc is sufficient to generate an ABI binary. On IRIX 5.1 with the IRIS Development Option 3.17, the following command line flags to the compiler are needed:
-L -L/usr/lib/abi is very important,
searching the standard IRIX library paths must be turned off.
On RISC/os 5.01 with ANSI C 3.11, the following command line switches
are used with /svr4/bin/cc:
ld directly?abild.
Using abild allows the specific compiler calling
conventions to be hidden. The specific invocation for three
different revisions of the Reference Platform are noted in the
rest of this section. Each is different, and there
is no guarantee that the methods will not continue to
change. Thus, the suggested compilation method is
simply to set an equate in the Makefile:
-abi flag to ld is sufficient to generate an ABI binary. On IRIX 5.1 with the IRIS Development Option 3.17, the following command line flags to the compiler are needed:
-L -L/usr/lib/abi is very important,
searching the standard IRIX library paths must be turned off.
On RISC/os 5.01 with ANSI C 3.11, the following command line switches
are used with /svr4/bin/ld:
If ld is to be used directly, it is useful to study the output
of cc -abi -v to get the flags and run-time startup files correct.
as, the -KPIC option must be supplied in order
to activate the PIC directives. It is suggested that assembly
language be assembled by the use of the abicc script rather
than calling as directly. The code itself must contain
a directive to produce PIC code:
check_abi_compliance. It reports
references that are outside the ABI, and also missing references
that are required by the ABI.
The tool check_for_syscalls can be used to check that
an executable makes no system calls directly. All system calls
are to be made by ABI-specified DSOs.
On the IRIX Reference Platform, elfdump can be used to
examine information about an ELF file. . A combination of
dump and ldd may provide similar functionality
on other platforms.
More sophisticated application checkers are under development and will be available in the future.
-KPIC and -G0 options were necessary.
On IRIX 5.2, abild should be used to make the DSO. It takes
the -G flag to do this. On IRIX 5.1, the -shared
flag is needed. Note that abicc is not able to make a
DSO directly, the objects need to be built first, then abild
called to link the DSO.
If DSOs are attached via dlopen,
some care must be taken
with the visibility of symbols.
To check a DSO to make sure it is ABI compliant, run
check_abi_interface on it. It may be worthwhile
to construct a list of entry points in the DSO and
install it in /usr/lib/abi/data. In this way,
the interfaces provided by the DSO can be checked to
make sure that they don't accidentally pull in non-ABI
interfaces from other libraries (for example, references
to gethostname, which is not part of the ABI).
First, the compilation environments on the different systems come
from different sources, so getting the right arguments and flags
on each system can be pretty tricky, and in particular, may
require testing on each platform to get them right, which is at odds
with the Reference Platform concept. To alleviate this problem,
all the system suppliers have agreed to provide "standard"
compiler wrappers abicc and abild that interpret
arguments and flags from the SVR4 SGS.
Another potential problem is that libraries and include files outside the ABI are not guaranteed to be identical on all systems. Problems from this can only be avoided by careful planning when executing the port, and a thorough understanding of what is supported by the ABI. When linking an executable on the Reference Platform it is permissible to link in code from static archives that are not explicitly specified by the ABI, as long as those routines do not themselves use non-abi facilities. This has the potential for problems for on-site linkage, since it may cause differences in behavior if those static archives are implemented differently on the target than on the Reference Platform. Programs which are fully linked on the RP, on the other hand, will be consistent since they'll always have the RP version. Thus, caution is advised when requiring non-ABI libraries for an on-site linking situation.
Note that when ABI compliant libraries and object files are linked on a target system, the ABI specification does not require that the resulting executable be ABI compliant. However, the resulting binary must run on the target system if all the pieces of the original application were ABI compliant and the application would have run if linked on the Reference Platform.
As specific examples, the Math library, libm.a, is
guaranteed to be compatible on all the ABI platforms,
and can safely be used for on-site linkage.
The curses library (libcurses) is known to depend
on private interfaces in libc.so.1 and should not
be used for programs which will be on-site linked, and
probably should be completely avoided except for
queries (obtaining terminal information should be safe).
The BSD compatibility library (libucb) may be
incompatible across versions and should be avoided for
on-site linkage.
The Motif library is a supported ABI library, and the ABI platform vendors have pledged to "make it work", but application vendors should take care to not depend too heavily on specific features of any specific OSF minor release. The release notes for the application should document the version of Motif it was built against for reference purposes.
pkgmk, pkgtrans, etc.),
or use their own packaging and installation tools. In the latter
case, tools must be restricted to those defined in chapter 8
of the gABI and the Conformance Guide.
Nodes for standard devices are provided in /dev/abi.
See Chapter 2 of the Black Book for the device names.
/opt/pkg,
package objects that change in normal operations (such as log files) in
/var/opt/pkg, and machine-specific configuration files in
/etc/opt/pkg. Only package objects that must
reside in specific locations within the system file tree
in order to function properly (e.g., special files in /dev)
should be installed in those locations.
The Black Book extends these requirements slightly for efficiency
reasons (to keep search paths short); for example
executable objects installed in /opt/pkg/bin
may symbolically link files to /opt/bin.
See the Black Book for details.
ABI platforms are required to provide the directories
/opt/bin, /opt/man, and /opt/include.
When constructing installation scripts or pkgmap files,
be aware that the /opt subtree may well be symbolically
linked to someplace else - any existing links should be
preserved.